src/test/http_openai_handler_test.cpp:3902

• Same issue as parseResponses(): EXPECT_FALSE on parse errors is non-fatal, so the helper can proceed to construct/parse a handler against an invalid document and return a status that may not reflect the original failure clearly. Consider using ASSERT_FALSE for JSON parsing failures (or returning an explicit InvalidArgument status when doc.HasParseError() is true).

    doc.Parse(json.c_str());
    EXPECT_FALSE(doc.HasParseError()) << json;
    std::optional<uint32_t> maxTokensLimit;
    uint32_t bestOfLimit = 0;
    std::optional<uint32_t> maxModelLength;
    auto apiHandler = std::make_shared<ovms::OpenAIResponsesHandler>(
        doc, ovms::Endpoint::RESPONSES, std::chrono::system_clock::now(), tokenizer);
    return apiHandler->parseRequest(maxTokensLimit, bestOfLimit, maxModelLength);

src/test/http_openai_handler_test.cpp:3915

• parseResponses() returns nullptr after ADD_FAILURE() when parsing fails; downstream helpers/tests (e.g., expectResponsesEquivalentToChatCompletions) dereference the returned pointer without asserting non-null, which can crash the test and obscure the real failure. Add an ASSERT_NE(apiHandler, nullptr) at the start of consumers or refactor the helper to fail fatally.

    doc.Parse(json.c_str());
    if (doc.HasParseError()) {
        ADD_FAILURE() << "Failed to parse JSON: " << json;
        return nullptr;
    }

src/llm/apis/openai_responses.cpp:550

• ProcessedJsonSink::emitStandaloneReasoning() omits the "content" field entirely. Templates that access message.content unconditionally will fail on such messages. Emit "content": "" (empty string) for standalone reasoning turns to keep processedJson compatible with a wider set of templates.

    void emitStandaloneReasoning(const std::string& reasoning) {
        rapidjson::Value msgObj(rapidjson::kObjectType);
        msgObj.AddMember("role", rapidjson::Value("assistant", alloc), alloc);
        msgObj.AddMember("reasoning_content", rapidjson::Value(reasoning.c_str(), alloc), alloc);
        messagesArray.PushBack(msgObj, alloc);

src/llm/apis/openai_responses.cpp:660

• parseInput() logs “Parsed responses input … without mutating request JSON”, but parseResponsesPart() now mutates doc before calling parseInput (tools normalization and potentially adding chat_template_kwargs). This debug message is misleading; consider rewording it or moving the tools normalization to after parseInput so the statement remains true.

    } else {
        return absl::InvalidArgumentError("input is not a string or array");
    }

    SPDLOG_LOGGER_DEBUG(llm_calculator_logger, "Parsed responses input directly to chat history without mutating request JSON");
    return absl::OkStatus();

src/test/http_openai_handler_test.cpp:708

• This comment says “For Responses, processedJson is always built from chatHistory”, but the updated Responses implementation now builds processedJson directly from the original input (including reasoning/function_call handling) rather than re-serializing chatHistory. Please update the comment to reflect the current contract to avoid confusion when maintaining these tests.

    ASSERT_NE(apiHandler, nullptr);

    // For Responses, processedJson is always built from chatHistory.
    // For chat/completions with simple text, processedJson is empty (original body is used instead).
    // In both cases, the chatHistory should be equivalent.